Certificates,
and the claims they represent, are a secure, general-purpose method for
proving identity. They embody a robust security mechanism that makes
them a great option for encryption and authentication. WCF uses
industry-standard X.509 certificates, which are widely adopted and used
by many technology vendors. Internet browsers and Internet servers use
this format to store encryption keys and signatures for SSL
communication on the Web. Certificates provide strong encryption and
are well understood and documented.
The
primary disadvantages of certificates are the expense of acquiring them
for production from a third-party authority and the complexity
associated with provisioning them. How do you distribute them? What do
you do if one is stolen? How do you recover data after one is lost? If
you store them on a client computer, how can you access information
from the road? A variety of solutions address these problems, from
storing certificates in a directory within an intranet or on the public
Internet, to storing them in Smart Cards that we can carry in our
wallets. Regardless of the provisioning solution, certificates are a
good option for encryption and authentication.
1. Concepts
The
overall concept of message encryption with asymmetric keys is fairly
simple. Imagine an algorithm that can encrypt an arbitrary string using
one key and that can decrypt it with another key. Now imagine that I
have a pair of those keys, and I make one of them public so that
everyone on the Internet can see it, but I keep the other one private
so that only I can see it. If my friend wants to send me a message, he
looks up my public key, runs the algorithm to encrypt the message, and
sends it. If the encrypted message is intercepted by my enemy, that
person can’t read it because only I, with my private key, can decrypt
it. When I send a response back to my friend, I look up his public key,
run the algorithm to encrypt the response, and send it. Again, only he
can decrypt the encrypted messages, so it will be kept confidential
between us.
Digital
signatures use message encryption, but in reverse. A digital signature
is simply a string that is encrypted with a private key so that it can
only be decrypted with a corresponding public key. The correct
decryption of the string (for example, my name) is public information,
so after someone decrypts the string using my public key, the person
can verify that my name was stored in the message.
Trust
is another important aspect of certificates. In our example of
exchanging messages with a friend, how do we know that we have the
public key of our friend and not of our enemy? For a client and service
to trust that each other’s certificates are correct, valid, and have
not been revoked, they must trust a common authority. It’s okay if the
client and service use certificates issued by different authorities, as
long as those authorities both trust a third, common authority. The
common authority is often referred to as the root authority, which
typically is self-signed, meaning that it doesn’t trust anyone else.
When a client receives a certificate from a service, it looks at the
certification path of the service certificate to see if the path is
valid and terminates at a trusted authority. If so, the client trusts
that the certificate is valid; if not, it rejects it. There are
provisions in WCF for disabling the certification path validation so
that untrusted certificates can be used in development and testing.
2. Setup
Certificates
can be used for transport- or message-level security. A commonly used
transport-level encryption option, SSL, is applied to the transport by
using a certificate on the server. Message-level encryption works on
individual messages. Whereas transport-based encryption requires a
certificate to be installed with the service, message-based encryption
supports a variety of modes with client and/or server certificates.
Listing 1 shows the commands that run on Vista to generate the necessary certificates. Makecert.exe creates a certificate. The -pe switch makes the private key exportable. The -n switch defines the name of the certificate that will be the name that is used for authentication. The -sv switch defines the private key file. The -sky
switch can be “exchange” or a digital signature. Pvt2pfx is a utility
that combines the private key and public key into a single file.
If you’re developing on one machine, change the name MyServer to localhost. All other instructions will remain the same.
Note: Production Certificates
Keep in mind that certificates generated in this fashion should not
be used in production scenarios. Certificates for use in production
environments should be requested from a trusted third-party certificate
authority.
Listing 1. Generating Certificates
makecert.exe -r -pe -sky exchange
-n "CN=MyClientCert" MyClientCert.cer
-sv MyClientCert.pvk
pvk2pfx.exe -pvk MyClientCert.pvk
-spc MyClientCert.cer
-pfx MyClientCert.pfx
makecert.exe -r -pe -sky exchange
-n "CN=MyServer.com" MyServerCert.cer
-sv MyServerCert.pvk
pvk2pfx.exe -pvk MyServerCert.pvk
-spc MyServerCert.cer
-pfx MyServerCert.pfx
|
The
.cer file is the public key, the .pvk file is the private key, and the
.pfx file is a key exchange file that contains both. The following keys
must be installed using the Certificates snap-in in the Microsoft
Management Console.
Install the following on the server, in the local computer certificate store:
Import MyServerCert.pfx to the Personal folder.
This enables the server to decrypt messages that have been encrypted
with its public key. It also enables the server to encrypt messages
with its private key.
Import MyClientCert.cer to the Trusted People folder. This
enables the server to decrypt messages that have been encrypted with
the MyClientCert private key, such as data messages and digital
signatures for authentication. It also enables the server to encrypt
messages with the MyClientCert public key.
Install the following on the client, in the current user certificate store:
Import MyClientCert.pfx to the Personal folder.
This enables the client to decrypt messages that have been encrypted
with its public key. It also enables the client to encrypt messages
with its private key.
Import MyServerCert.cer to the Trusted People folder.
This enables the client to decrypt messages that have been encrypted
with the MyServerCert private key, such as data messages and digital
signatures for authentication. It also enables the client to encrypt
messages with the MyServerCert public key.
